Hal Finney wrote:
> it is mentioned that if a broadcast transaction does not reach all nodes,
> it is OK, as it will get into the block chain before long. How does this
> happen - what if the node that creates the "next" block (the first node
> to find the hashcash collision) did not hear about the transaction,
> and then a few more blocks get added also by nodes that did not hear
> about that transaction? Do all the nodes that did hear it keep that
> transaction around, hoping to incorporate it into a block once they get
> lucky enough to be the one which finds the next collision?

Right, nodes keep transactions in their working set until they get into a block.  If \
a transaction reaches 90% of nodes, then each time a new block is found, it has a 90% \
chance of being in it.


> Or for example, what if a node is keeping two or more chains around as
> it waits to see which grows fastest, and a block comes in for chain A
> which would include a double-spend of a coin that is in chain B? Is that
> checked for or not? (This might happen if someone double-spent and two
> different sets of nodes heard about the two different transactions with
> the same coin.)

That does not need to be checked for.  The transaction in whichever branch ends up \
getting ahead becomes the valid one, the other is invalid.  If someone tries to \
double spend like that, one and only one spend will always become valid, the others \
invalid.

Receivers of transactions will normally need to hold transactions for perhaps an hour \
or more to allow time for this kind of possibility to be resolved.  They can still \
re-spend the coins immediately, but they should wait before taking an action such as \
shipping goods.  


> I also don't understand exactly how double-spending, or cancelling
> transactions, is accomplished by a superior attacker who is able to muster
> more computing power than all the honest participants. I see that he can
> create new blocks and add them to create the longest chain, but how can
> he erase or add old transactions in the chain? As the attacker sends out
> his new blocks, aren't there consistency checks which honest nodes can
> perform, to make sure that nothing got erased? More explanation of this
> attack would be helpful, in order to judge the gains to an attacker from
> this, versus simply using his computing power to mint new coins honestly.

The attacker isn't adding blocks to the end.  He has to go back and redo the block \
his transaction is in and all the blocks after it, as well as any new blocks the \
network keeps adding to the end while he's doing that.  He's rewriting history.  Once \
his branch is longer, it becomes the new valid one.

This touches on a key point.  Even though everyone present may see the shenanigans \
going on, there's no way to take advantage of that fact. 

It is strictly necessary that the longest chain is always considered the valid one.  \
Nodes that were present may remember that one branch was there first and got replaced \
by another, but there would be no way for them to convince those who were not present \
of this.  We can't have subfactions of nodes that cling to one branch that they think \
was first, others that saw another branch first, and others that joined later and \
never saw what happened.  The CPU power proof-of-work vote must have the final say.  \
The only way for everyone to stay on the same page is to believe that the longest \
chain is always the valid one, no matter what.


> As far as the spending transactions, what checks does the recipient of a
> coin have to perform? Does she need to go back through the coin's entire
> history of transfers, and make sure that every transaction on the list is
> indeed linked into the "timestamp" block chain? Or can she just do the
> latest one? 

The recipient just needs to verify it back to a depth that is sufficiently far back \
in the block chain, which will often only require a depth of 2 transactions.  All \
transactions before that can be discarded.


> Do the timestamp nodes check transactions, making sure that
> the previous transaction on a coin is in the chain, thereby enforcing
> the rule that all transactions in the chain represent valid coins?

Right, exactly.  When a node receives a block, it checks the signatures of every \
transaction in it against previous transactions in blocks.  Blocks can only contain \
transactions that depend on valid transactions in previous blocks or the same block.  \
Transaction C could depend on transaction B in the same block and B depends on \
transaction A in an earlier block.


> Sorry about all the questions, but as I said this does seem to be a
> very promising and original idea, and I am looking forward to seeing
> how the concept is further developed. It would be helpful to see a more
> process oriented description of the idea, with concrete details of the
> data structures for the various objects (coins, blocks, transactions),
> the data which is included in messages, and algorithmic descriptions
> of the procedures for handling the various events which would occur in
> this system. You mentioned that you are working on an implementation,
> but I think a more formal, text description of the system would be a
> helpful next step.

I appreciate your questions.  I actually did this kind of backwards.  I had to write \
all the code before I could convince myself that I could solve every problem, then I \
wrote the paper.  I think I will be able to release the code sooner than I could \
write a detailed spec.  You're already right about most of your assumptions where you \
filled in the blanks.

Satoshi Nakamoto
